Qualify Customer for Loyalty Tier Based on Action
This use case describes the workflow of qualifying a customer for a new loyalty tier when they take an action. Once the action is taken, SessionM determines if it generates enough points to satisfy the event behavior ruleset that governs how point-based outcomes are awarded.
Part of configuring a SessionM implementation is the definition of a point economy, which provides the foundation for points-based loyalty programs. The key components of a point economy are point accounts, along with policies that define how points are redeemed and expired. With a point economy configured, a client can then define a tiered loyalty program, which can offer rewards based on events triggered when customers perform certain actions, such as visiting a website. The tiers within the loyalty program allow a client to offer different levels of rewards to their customers, each with benefits that recognize a customer's event history and brand engagement.
The provisioning of points to point accounts can happen several ways:
-
Awarded through a campaign.
-
Awarded as an outcome of an event or transaction.
-
Deposited by a customer service representative adding points manually.
This use case features a points-based outcome based on an event - a customer signing in to a website.
Customer Journey
One helpful way of understanding this use case is to consider how it reflects the customer's experience, or journey, in the "real world."
Customer signs in to website selling international coffee by the pound
Client middleware sends sign-in event to SessionM for evaluation against tier ruleset
10 points are added to the customer's point account if event meets ruleset criteria
Customer is then promoted to new tier if point account total qualifies for tier change
Current loyalty tier status displayed for customer
Platform Configuration
Before implementing this use case, ensure the following have been configured:
Points
Points account created in environment.
Economies
Point economy with at least two tiers set up, configured with the following behaviors for each tier:
- Entrance behavior - Set amount of points and limit to particular point account for entering tier
- Event behavior - Award points per event to point account in order to allocate points per action.
- Maintenance behavior - Set to run at regular interval to ensure tier members can remain in tier.
Sequence Diagram
See the overall flow for this use case below.
Alternative Path
In the diagram above, step 4 adds points to the customer's account based on logic configured in the tier ruleset that triggers an award of points when an action is taken. But another option is to sidestep such logic and simply deposit points into the account directly using this endpoint, detailed in the UserPoints API documentation: POST /api/1.0/user_points/deposit
.
In addition, consider step 7, which makes a request for the customer's tier level status using the UserTiers API (Incentives domain package). This information, however, can also be obtained using the Standard Profile API (for basic tier in primary system) or the Custom Profile API (for tiers in all systems). These operations are detailed in the task, Get Customer Profile. Note that should you use the endpoint to retrieve the combined profile (standard/custom). Doing so ensures all of the data can be seen for all tiers and systems. However, you may want to filter the data being returned by setting additional parameters detailed in the "API Endpoint Constraints" section of the Get Customer Profile task article.
Best Practices
Consider setting limits on earning frequencies.
Consider using rolling point expiration policies to govern the point accounts.
With respect to tier maintenance:
-
Can take several days to run.
-
Drops customers from one tier to a lower tier. Tier level of a customer drops only when tier maintenance is run.
-
Other behaviors and associated outcomes may be scheduled to run at the same time maintenance processes are set up to run. This overlap of having two or more behaviors working on the same data at the same time may cause unexpected results. Best to avoid potential race conditions during maintenance.
When ranking outcomes designated for behaviors, bear in mind that the rank controls when the outcome starts. When rankings control a subsequent outcome, it runs after the previous, higher-ranked outcome begins, not after the previous outcome finishes.